Release 10.1A: OpenEdge Development:
Progress Dynamics Basic Development

Guidelines for using SBOs

The SBO has three fundamental purposes:

To let you define a single database transaction for a complex data set, including data from multiple tables all updated on the client in a single operation, either in a one-to-one or master-detail relationship.
To provide a place where you can define business logic that must examine data from all of those data sets at the same time.
Progress Dynamics supports dynamic SBOs. Dynamic SBOs support data logic procedures like SDOs.
Note: When using the SBO as a data source, the ForeignFields property must be qualified with the name of the parent SDO.

It is important to note that in most cases you should only use an SBO if records from all the tables are added or updated on the client and returned to the server together. If a user update to a single table on the client results in executing business logic that updates other related tables on the server, this does not require using an SBO.

For example, if your application is browsing data in a master-detail relationship, such as Orders and their OrderLine records, but the two tables do not need to be updated in the same transaction, then you can and should continue to use multiple SDOs without the SBO container just as you would in earlier Version 9 releases. You can make the master SDO the Data-Source for the detail SDO and define the foreign key values that relate them. The SDOs will automatically be kept in sync as the master is repositioned, and users can update one SDO or the other. An update to either table from the client can execute whatever business logic it needs to on the server, including updates to any number of other related tables.

However, if you really need to allow users to make changes to both master and detail on the client (even potentially multiple levels of detail) in the same transaction and to commit all of those changes at once, then you can use the SBO to represent the data relationships. Likewise, if you need to define business logic that looks at changes to both master and detail at the same time, then you can also use the SBO.

It is entirely likely that your application will have places where you should use an SDO directly, and places where you should use that same SDO inside an SBO. For example, if at one point in your application the user can browse Orders, you should just use the Order SDO. If the application window just allows the Order to be updated, then you should also use the SDO by itself. If you want to show OrderLine records of the Order but not update them in the same transaction, then the Order SDO should be the Data-Source for an OrderLine SDO. If the application window allows one or more OrderLine records to be updated but does not allow updates to the Order at the same time, then you should use the OrderLine SDO. If you need to allow multiple OrderLine records to be changed together, then you can use the OrderLine SDO together with the Commit/Undo band of a SmartToolbar.

But if your application logic requires that an Order and its OrderLine records be added or updated in the same database transaction, and that business logic must control and validate those compound updates, then you can use a SmartBusinessObject that contains the Order SDO (as Data-Source) and the OrderLine SDO (as Data-Target). Each SDO can continue to have its own business logic, which affects updates to that single object. Any additional business logic written in the SBO will be executed in addition to the logic in each SDO.